1. Field of the Invention
The present invention relates to data acquisition (DAQ) systems comprising application software, device interface software, and DAQ hardware and particularly such systems in which the device interface software provides an Application Programming Interface (API) to the application software.
2. Description of the Related Art
Scientists and engineers often use DAQ systems to perform a variety of functions, including laboratory research, process monitoring and control, data logging, analytical chemistry, test and analysis of physical phenomena, and control of mechanical or electrical machinery, to name a few examples. A DAQ system typically includes transducers and other detecting means for providing "field" electrical signals representing a process, physical phenomena, equipment being monitored or measured, etc. For example, detectors and/or sensors are used to sense the on/off state of power circuits, proximity switches, push-button switches, thermostats, relays or even the presence of positive or negative digital logic-level signals.
A typical DAQ system comprises a computer system with DAQ hardware, wherein the DAQ hardware is typically plugged into one of the I/O slots of the computer system. The field signals are provided to the DAQ hardware. In another common DAQ system configuration, the DAQ hardware is coupled to the computer system via other means such as through a VXI (VME eXtensions for Instrumentation) bus, a GPIB (General Purpose Interface Bus), a serial port, or parallel port of the computer system. Optionally, the DAQ hardware comprises signal conditioning modules which receive the field signals and condition the signals to be acquired.
The DAQ hardware is configured and controlled by DAQ software executing on the computer system. The DAQ software for configuring and controlling the DAQ system typically comprises of two portions: the device interface software and the application software, or the application. The device interface software serves to interface the DAQ hardware to the application. The device interface software, is typically supplied by the manufacturer of the DAQ hardware or by some other third party software vendor. The application is typically developed by the user of the DAQ system and is tailored to the particular function which the user intends the DAQ system to perform. The DAQ hardware manufacturer or third party software vendor sometimes supplies the application software for some applications which are common, generic or straightforward.
Referring now to FIG. 1, a block diagram of portions of a DAQ system illustrating the relationship between a DAQ application 12, DAQ device interface software with an enumerated function API 14, and DAQ hardware 16 is shown. The DAQ hardware 16 has associated attributes. Common examples of DAQ hardware attributes and/or attributes of the software controlling the DAQ hardware 16 are the range of input values (voltages, currents, etc.) which the DAQ hardware will acquire; the manner of coupling the DAQ hardware 16 to the field signals (e.g., DC or AC); the input mode of the acquired signals (e.g., differential or single-ended); various acquisition trigger related attributes such as trigger mode, trigger source, trigger action, trigger level, etc.; attributes relating to acquisition clocks; the size of the buffer for receiving the acquired data; and the engineering units associated with the values of the acquired data.
The DAQ application 12 provides the interface to the user of the DAQ system, configures the attributes (such as those previously listed) of the DAQ hardware 16 and controls the DAQ hardware 16 to perform the acquisition of data, typically in response to input from the user. For example, in a DAQ system for acquiring analog input signals from a television set, the application may call functions of the device interface software to configure the values of the trigger level, sample rate, and upper and lower input voltage levels of the DAQ hardware. Then the application may call upon the device interface software to control the DAQ hardware to begin acquiring data from the television set and then stop acquiring data at a certain point in time or upon detection of a certain event, such as a buffer for the acquired data becoming full.
The device interface software 14 commonly includes, inter alia, low-level device drivers for communicating with the DAQ hardware 16. In particular, the device drivers perform input/output operations to DAQ hardware 16 registers and memory, service interrupts from the DAQ hardware 16, perform data transfers from or to the DAQ hardware 16 and execute at the required operating system privilege level to access the DAQ hardware 16. In addition, the device interface software 14 typically comprises function libraries or dynamic link libraries (DLL) which the application 12 may either link with or execute, respectively. The libraries contain functions which the application 12 invokes to configure and control the DAQ hardware 16. An example of DAQ device interface software 14 is the NI-DAQ product developed by "NATIONAL INSTRUMENTS CORPORATION."
The device interface software 14 provides a specified interface to the functions in its libraries. This interface is commonly referred to as the Application Programming Interface (API) since it specifies the interface which the application software program 12 uses to access the library functions. The API specifies, inter alia, the function names, the input parameters for each function, the acceptable values of the input parameters, and the output values of each function. The prior art device interface software 14 of FIG. 1 presents an enumerated function API for the application 12. A enumerated function API typically specifies a different function to set and/or get the value of each attribute. Further, the enumerated function API specifies a different function for each control action (i.e., start, stop, pause, resume, etc.) to be performed. Thus, with enumerated function API DAQ systems, a relatively large number of function calls exist in the API to accommodate the large number of attributes of the DAQ system.
Enumerated function API's often prove to be difficult to expand, scale and maintain. As new DAQ hardware is employed, new attributes associated with the new hardware must be configured. Hence, the API must be expanded by adding new functions to the API, or the existing functions must be changed to accommodate the new attributes. For example, consider a function in an enumerated function API for setting the data acquisition clock source. Suppose the caller of the current function specifies a parameter to choose an internal clock source, a counter output clock source, or an I/O connector pin clock source associated with integer values 0, 1 or 2, respectively, of the input parameter. Then a new DAQ board is developed which provides yet a fourth type of clock source, which is not provided for in the current function. The new clock source allows a choice of one of a large number of signals from an external bus to be chosen as the clock source. The function must now be changed.
One possible solution is to change the function to associate a value 3 of the input parameter with the new clock source and add another input parameter which specifies which of the large number of external bus signals is to be the clock source. However, applications which assume the old function will no longer work with the new device interface software, i.e., they will either not compile with the new library functions (due to the added parameter in the parameter list) or they will cause errors when attempting to invoke the new library functions. Thus, existing applications which desire to use the new device interface software for reasons other than to utilize the new clock source attributes (such as to enjoy the benefit of bug fixes, code efficiency or performance) would have to be modified.
Another possible solution is to obsolete the old function name and create a new function with a new name and parameter list. However, again, existing applications would have to be modified to use the new device interface software. Further, if the number of attribute changes becomes relatively large over time, the numerous changes to the API may become very undesirable from a maintenance perspective.
Hence, DAQ device interface software providing an API which avoids the disadvantages of an enumerated function API, that is, an API which is more expandable, scaleable and maintainable, is desired.